Info-Mac 4/Info_Mac IV CD-ROM (Pacific HiTech Inc.)(August 1994).iso/Periodicals/CSMP/C.S.M.P. Digest, Issue 3.005

Internet Message Format | 1994-06-09 | 69KB

From: [e-mail] (Francois Pottier)
Subject: C.S.M.P. Digest, Issue 3.005
Date: Wed, 16 Mar 94 16:43:25 MET

C.S.M.P. Digest             Wed, 16 Mar 94       Volume 3 : Issue 5

Today's Topics:

        AppleScript: Compiled Script of Applets?
        Communications Tool Box Experts?
        Execution speed of compiled code
        How do I : find out more about an open resource file ?
        PopUpMenuControl v. 'mctb', help help
        TextEdit caret
        What language should I learn?



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  If you don't have access to news, you may
still be able to post messages to the group by using a mail server like
anon.penet.fi (mail [e-mail] for more information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                        Sends you a summary of commands
    subscribe csmp-digest Your Name    Adds you to the mailing list
    signoff csmp-digest            Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail]. Currently no previous volumes of the CSMP
digest are available there.

Also, the digests are available to WAIS users as comp.sys.mac.programmer.src.


-------------------------------------------------------

>From [e-mail] (Jerome Chan)
Subject: AppleScript: Compiled Script of Applets?
Date: Sat, 26 Feb 1994 13:05:59 -0500
Organization: TofuSoft

What are the advantages of Compiled scripts and Applets? Are they both the
same? Can I run multiple scripts/applets at a time?

--
 The Evil Tofu (Only Human)

+++++++++++++++++++++++++++

>From [e-mail] (John Schettino)
Date: Mon, 28 Feb 1994 13:02:42 GMT
Organization: GTE Labs, Waltham MA

In article <[e-mail]>
[e-mail] (Jerome Chan) writes:

> What are the advantages of Compiled scripts and Applets? Are they both the
> same? Can I run multiple scripts/applets at a time?
>
> --
>  The Evil Tofu (Only Human)

compiled scripts correspond to reusable compiled libs in other
languages. You cannot "run" them, you access them using:

-- this is meant to be applescript
set myfuncts to load script file "myhd:mylibs:functs"

-- where "myhd:mylibs:functs" is the full path to the file you saved
-- as a compiled script.

-- assume that there are two handlers in the file functs called foo and
bar. you
-- access them using:
myfuncts's foo()
myfuncts's bar()

-- 'load script' is an applescript extention (found in System
Folder:Extentions:Scripting Additions:Load Script) and has a dictionary
that you can see by droping this file on the script editor.


John Schettino - [e-mail]
GTE Laboratories, Inc

+++++++++++++++++++++++++++

>From [e-mail] (Mark Minshull)
Date: Tue, 1 Mar 1994 23:02:53 GMT
Organization: OpenDoc Engineering

In article <[e-mail]>, [e-mail] (John Schettino) wrote:

> In article <[e-mail]>
> [e-mail] (Jerome Chan) writes:
>
> > What are the advantages of Compiled scripts and Applets? Are they both the
> > same? Can I run multiple scripts/applets at a time?
> >
> > --
> >  The Evil Tofu (Only Human)
>
> compiled scripts correspond to reusable compiled libs in other
> languages. You cannot "run" them, you access them using:
>

You *can* run compiled scripts by using the "run script" command, or
"telling" the script object to run.  For example, consider the script
below, saved in the file "hd:folder:hello world" as a compiled script:

         display dialog "hello world"

      on foo(x)
        return x + 2
   end foo

      on bar(y)
        return y - 2
   end bar

You can execute this as follows:

      run script file "hd:folder:hello world"

which would display a dialog.  If you want to load the script as a library
and run it you would script:

      set myFooLib to load script file "hd:folder:hello world"
      tell myFooLib
      run         -- display's a dialog
      foo(2)      --   => 4
      bar(2)      --   => 0
   end tell

Finally, "applets" are AppleScripts saved as small applications.  You can
have any number of them running at once (up to the limit of memory).  If
it's a "stay open" script application one can access it's handlers as
follows:

   tell application "hello world"    -- launches application if not running
      run         -- display's a dialog
      foo(2)      --   => 4
      bar(2)      --   => 0
            quit        -- quit's the script application
   end tell

Mark
--
Mark Minshull                       :
OpenDoc Engineering Manager         :          Apple usually doesn't care
Apple Computer, Inc.                :          what I say... When they do
1 Infinite Loop, MS 303-3A          :          my opinions are my own.
Cupertino, CA  95014                :

+++++++++++++++++++++++++++

>From [e-mail] (John Schettino)
Date: Wed, 2 Mar 1994 12:36:36 GMT
Organization: GTE Labs, Waltham MA

In article <[e-mail]>
[e-mail] (Mark Minshull) writes:

> In article <[e-mail]>, [e-mail] (John Schettino) wrote:
>
> > In article <[e-mail]>
> > [e-mail] (Jerome Chan) writes:
> >
> > > What are the advantages of Compiled scripts and Applets? Are they both the
> > > same? Can I run multiple scripts/applets at a time?
> > >
> > > --
> > >  The Evil Tofu (Only Human)
> >
> > compiled scripts correspond to reusable compiled libs in other
> > languages. You cannot "run" them, you access them using:
> >
>
> You *can* run compiled scripts by using the "run script" command, or
> "telling" the script object to run.  For example, consider the script
> below, saved in the file "hd:folder:hello world" as a compiled script:
>
>                  display dialog "hello world"
>
>           on foo(x)
>             return x + 2
>    end foo
>
>           on bar(y)
>             return y - 2
>    end bar
>
> You can execute this as follows:
>
>           run script file "hd:folder:hello world"
>
> which would display a dialog.  If you want to load the script as a library
> and run it you would script:
>
>           set myFooLib to load script file "hd:folder:hello world"
>           tell myFooLib
>       run         -- display's a dialog
>       foo(2)      --   => 4
>       bar(2)      --   => 0
>    end tell
>

Yes, you can *load* a compiled script into your script and send it a
run command, but I guessed that he meant "Can you run a compiled script
*from the finder*" With this interpretation, the answer is "no". Your
answer is correct, and (I think) so is mine!

John Schettino - [e-mail]
GTE Laboratories, Inc

---------------------------

>From [e-mail] (Terry Monks)
Subject: Communications Tool Box Experts?
Date: Mon, 28 Feb 1994 19:08:40 GMT
Organization: Automata Design, Inc.

Are there any CTB experts out there? I need to send a setup string
to my USR modem from with a program. Not the CTB setup string,
but a AT&B1&H1 sort of thing. I know I can change the modem type
to Custom and change the modem setup string, but how do you do
this from within a CTB program? And where (if anywhere) is this
documented. How does the Apple Modem Tool know about the different
modes, and can I add one of my own.

I do (of course) have the Inside Mac CTB document, that is silent
on these interesting points...

Tel

--
Terry Monks    [e-mail]    Automata Design Inc    [phone]


+++++++++++++++++++++++++++

>From [e-mail] (Erik James Walter)
Date: 1 Mar 94 21:01:43 GMT
Organization: Pacer Software, Inc.

In article <[e-mail]> Terry Monks,
[e-mail] writes:
>Are there any CTB experts out there? I need to send a setup string
>to my USR modem from with a program. Not the CTB setup string,
>but a AT&B1&H1 sort of thing. I know I can change the modem type
>to Custom and change the modem setup string, but how do you do
>this from within a CTB program? And where (if anywhere) is this
>documented. How does the Apple Modem Tool know about the different
>modes, and can I add one of my own.
>
>I do (of course) have the Inside Mac CTB document, that is silent
>on these interesting points...
>

For starters, you could simply use the Serial tool and send the data
directly
to the modem.   If you look at GetConfig and SetConfig for tools, I think
that you'll find the information you need on setting a custom modem and
changing the tool settings.  Inside CTB doesn't say it directly, but you
can pass just one or two settings in the SetConfig call and it won't
affect
anything but the settings you pass to it.

If you want to do it with a custom modem type, there is no way to change
the
modem file from CTB, but you can just open the file yourself if you so
choose to (Not a good idea, however).

If timing isn't critical, why not just send the string after opening the
connection??


+-------------------------------------------++-------------------------
---+
| A man gazing at the stars is at the mercy ||     Erik Walter
 |
| of every puddle on the road.              ||     Macintosh Engineer
 |
| "Travel is lethal to prejudice."          ||     Pacer Software, Inc.
 |
| MARK TWAIN                                ||
 |
+-------------------------------------------++-------------------------
---+

+++++++++++++++++++++++++++

>From [e-mail] (Pete Gontier)
Date: Wed, 2 Mar 1994 00:36:05 GMT
Organization: cellular

I'm no CTB expert, but what the hell? This post has been here long
enough that I might as well take a shot at it.

[e-mail] (Terry Monks) writes:

>Are there any CTB experts out there? I need to send a setup string
>to my USR modem from with a program. Not the CTB setup string, but a
>AT&B1&H1 sort of thing. I know I can change the modem type to Custom
>and change the modem setup string, but how do you do this from within a
>CTB program?

You don't. The whole point of the CTB is that your program does not have
any control over the connection that the connection tool doesn't want
you to have. In most cases, this means you have very little control.
This is a feature -- you don't *want* control, because not only is
control a PITA, but what you get in exchange is the ability to use your
software with AppleTalk, TCP, and any other sort of connection for which
you have a tool.

One thing you might try is to use the Serial tool to send AT commands,
but if you'll watch the progress window as the modem tool opens a
connection, you'll see it does a pretty thorough job of blowing away any
previous configuration by using 'ATZ'. At least it does not do 'AT&F';
you might be able to slide something past it because of that.

If I understand correctly, you might not be able to guess which serial
port the modem is hooked up to, because the CTB allows programs to
register serial ports which are not the modem port or the printer port.
This would tend to foil attempts to tweak the modem with the Serial
Manager, as well.

You might just choose to skip the modem tool entirely and assume that
the serial tool is connected to a modem. You would have to write
your own code to send AT commands and parse responses. This is not
particularly difficult but can be frustrating if you have never done it
before. Getting it really robust is another story; there are hundreds of
modems out there, each with its own interpretation of the Hayes command
set.

>And where (if anywhere) is this documented.

It's not. It's implicit in the way the CTB works. To explain it would be
to explicitly document how to bypass the CTB.

>How does the Apple Modem Tool know about the different modes, and can I
>add one of my own.

In versions earlier than 1.5, I dunno. In 1.5, just select "Modify this
Menu..." from the 'Modem' popup menu. In my limited experience I have
done configurations for an Okitel 9600 and a Global Village TelePort
Gold. It's not hard. It's definitely the way to go if you have the
option.

>I do (of course) have the Inside Mac CTB document, that is silent
>on these interesting points...

That's because it's a general-case document and tries to keep its grubby
little fingers out of the domain of any particular tool. :-)
--
 Pete Gontier, CTO, Integer Poet Software; [e-mail]

---------------------------

>From [e-mail] (Francis H. Schiffer 3rd)
Subject: Execution speed of compiled code
Date: Tue, 1 Mar 1994 17:54:23 GMT
Organization: Self

I have noticed a number of posts recently asking about how to achieve the
best speed of processing on a Macintosh.  The responses have said little
about
the effects of your compiler, whereas the benchmarks published for
workstations
tend to focus on the effects of your compiler on benchmark speeds.

I attempted to see what are the effects of the compiler on the execution
speeds of a small number of benchmark programs using a IIfx running A/UX.
I had four compilers that I could use:
     cc    = the A/UX compiler supplied by Apple and Motorola,
     gcc   = the Gnu compiler version 2.5.7 ported to A/UX,
     TC    = Think C version 6.0.1, and
     SC++  = Symmantec C++ version 6.0.1.
The programs were benchmarks that have been used for workstation
benchmarking
with the minimum modifications necessary to run within the MacOS and/or
A/UX
environment.  For A/UX that means no modifications and for the MacOS
usually
only the inclusion of prototypes.  As these are ANSI style programs, the
Think console was used for output, but that processing was entirely outside
the timed sections.  In each case the benchmark times the computational
portion
of the program for a sufficient number of iterations to ensure that the
total
duration time was small compared to the timing quanta (typically
16.67 milliseconds).  In each case the application was built using the best
level of optimization offered by the compiler.

The results are shown in the following table where I have normalized the
results
to the speed of the fastest program .  The duration is the time it took the

fastest version of the program to execute the timed portion of the
benchmark.

                       cc      gcc      TC     SC++   Duration
Towers of Hanoi        1.00    0.79    0.81    0.68   37.4 sec
Heapsort               0.79    1.00    0.77    0.50   24.4 sec
Sieve of Eratosthenes  0.91    1.00    0.97    0.76   83.3 sec

It should be noted that part of the slowness of the MacOS compiled versions
may well be due to the fact that the timing routines on the A/UX side
discount
the system time from the running time, whereas the MacOS run times include
the system time.  All of the runs were done on a lightly loaded system, so
the effects should be small.  I, unfortunately, do not have the option to
take
down A/UX to run on a purely native MacOS to get a measure of this bias.
           skip
--
Francis H Schiffer 3rd  [e-mail] - my opinions only, those of
[e-mail]  stscic::schiffer   - my employer are unknown to me

---------------------------

>From [e-mail] (Harry A. Reinke)
Subject: How do I : find out more about an open resource file ?
Date: Wed, 23 Feb 1994 14:52:09 GMT
Organization: Drexel University, Phila. Pa.

I have been having problems with some resources, I do a CountResources and
I get 2 or 3 more than are available in my resource file.  The resource
type is 'hdrs' so I know that the syste and other open resource files do
not have any such resources.

Am I writeing a resource without removing the old ?  I remember something
about if you're not carefull you can save a particular resource type and
number without destroying the prvious which causes problems.

I have used HomeResFile and its return numbers that I didn't expect (like
2546 instead of 2640) but is not part of the system/ROM.  How do I find
out more about an open res file if I have its ref num ?  I would love to
associate a filename with the numbers returned from HomeResFile.

Thanks.



+++++++++++++++++++++++++++

>From [e-mail] (WalrathW)
Date: 28 Feb 94 11:18:29 -0500
Organization: RFE/RL Inc.

In article <[e-mail]>
[e-mail] (Harry A. Reinke) writes:

> I have been having problems with some resources, I do a CountResources and
> I get 2 or 3 more than are available in my resource file.  The resource
> type is 'hdrs' so I know that the syste and other open resource files do
> not have any such resources.
>
> Am I writeing a resource without removing the old ?  I remember something
> about if you're not carefull you can save a particular resource type and
> number without destroying the prvious which causes problems.
>
> I have used HomeResFile and its return numbers that I didn't expect (like
> 2546 instead of 2640) but is not part of the system/ROM.  How do I find
> out more about an open res file if I have its ref num ?  I would love to
> associate a filename with the numbers returned from HomeResFile.
>
> Thanks.
>
>
You can use the FILE dcmd in Macsbug to accomplish this. If you don't
have it, check ftp.apple.com. If you don't find it there, send mail and
i'll dig it up for you.

You could also just write a little hack to walk through the FCB data
structures (or better yet use _PBGetFCBInfo). I presume there is info
on this in New Inside Mac:Files, and you should also find something in
ThinkRef. "Debugging Macintosh Software w/ Macsbug" is a book worth
having, and also another source of info on these topics.

I started writing a little app last week to display resource chains and
the resMap's of open resource files, but kind of tabled the project
after finding the tool I wanted already written. I have code for
walking a resMap as well as getting the file name of an open res file,
given its refNum.  Mail me if you want any of this code. It's not
polished since it wasn't for distribution, but I think I added some
comments here and there   :-)   .

cheers,
______o0o______
 Wayne Walrath
 RFE/RL Inc.

+++++++++++++++++++++++++++

>From [e-mail] (Jim Brunner)
Date: 1 Mar 94 17:16:59 GMT
Organization: (none)


In article <[e-mail]>, you write:
>
> In article <[e-mail]>
> [e-mail] (Harry A. Reinke) writes:
>
> > I have been having problems with some resources, I do a CountResources
and
> > I get 2 or 3 more than are available in my resource file.  The
resource
> > type is 'hdrs' so I know that the syste and other open resource files
do
> > not have any such resources.
> >
> > Am I writeing a resource without removing the old ?  I remember
something
> > about if you're not carefull you can save a particular resource type
and
> > number without destroying the prvious which causes problems.


CountResources counts all resources in all resource files (you mention that
the type you are counting is not in other resource files like system but
you may want to do this anyway) "Count1Resources" only counts in the
current resource file.

As to if a resource file can contain the same resource type/id twice, the
answer is YES!  I had this problem once.  If you do an AddResource and the
resource already exists, there will be a second one added.  You'll need to
watch this.

---
Jim Brunner ([e-mail])

---------------------------

>From [e-mail] (Alex Curylo)
Subject: PopUpMenuControl v. 'mctb', help help
Date: 28 Feb 94 01:38:42 GMT
Organization: MIND LINK! - British Columbia, Canada

I have a DITL resource, used in a CTB setup, that has a popup menu control in
it. Since the popup menu would look much more cool in color, I created a
'mctb' for it in ResEdit, which displays the menu correctly. But when the
menu is popped up in the dialog courtesy of the Dialog Manager, it's in bogus
black and white. Is there some trick to getting a popup menu control to know
about an 'mctb' for its 'MENU'?

+++++++++++++++++++++++++++

>From [e-mail] (Leonard Rosenthol)
Date: Mon, 28 Feb 1994 18:33:43 GMT
Organization: Aladdin Systems, Inc.

In article <[e-mail]>, [e-mail] (Alex
Curylo) wrote:

> I have a DITL resource, used in a CTB setup, that has a popup menu control in
> it. Since the popup menu would look much more cool in color, I created a
> 'mctb' for it in ResEdit, which displays the menu correctly. But when the
> menu is popped up in the dialog courtesy of the Dialog Manager, it's in bogus
> black and white. Is there some trick to getting a popup menu control to know
> about an 'mctb' for its 'MENU'?
>
     No trick - it doesn't work!   The PopUpCDEF doesn't load the 'mctb'
resource due to visual problems reported in earlier versions of same...

Leonard
P.S. Hey Jon - this should probably go in the FAQ!
--------------------------------------------------------------------------
Leonard Rosenthol                      Internet:       [e-mail]
Director of Advanced Technology        AppleLink:      MACgician
Aladdin Systems, Inc.                  GEnie:          MACgician

+++++++++++++++++++++++++++

>From [e-mail] (Terje Finstad)
Date: Mon, 28 Feb 1994 20:03:40
Organization: Dept. Physics, Univ. Oslo

In article <[e-mail]>,
[e-mail] (Leonard Rosenthol) wrote:
> In article <[e-mail]>, [e-mail] (Alex
> Curylo) wrote:
> > I have a DITL resource, used in a CTB setup, that has a popup menu control in
> > it. Since the popup menu would look much more cool in color, I created a
> > 'mctb' for it in ResEdit, which displays the menu correctly. But when the
> > menu is popped up in the dialog courtesy of the Dialog Manager, it's in bogus
> > black and white. Is there some trick to getting a popup menu control to know
> > about an 'mctb' for its 'MENU'?
>
>      No trick - it doesn't work!   The PopUpCDEF doesn't load the 'mctb'
> resource due to visual problems reported in earlier versions of same...

I may have totally misunderstood,
I _had similar problems to what Alex Curylo. _Now I always get colors as I
want to in the PopUp.  Am I currently doing things wrong then?
I am just calling insertmenu(myMenuHandle, -1) on a hit in the popup area
and then PopUpMenuSelect ,  ( I've heard this is outdated, is that it? ) On
startUp I just do a myMenuHandle := getmenu(kPopUpMenuID);
I had previously been led to belive I should call deletemenu after the menu
had been closed/hidden by PopUpMenuSelect.  This caused the color to
disappear. Now it does not. The menu does not get inserted multiple times
in the menu list as far as I can tell )

Terje

+++++++++++++++++++++++++++

>From [e-mail] (Brian Hall)
Date: Tue, 1 Mar 1994 05:37:07 GMT
Organization: Mark/Space Softworks

[e-mail] (Terje Finstad) writes:

>I may have totally misunderstood,
>I _had similar problems to what Alex Curylo. _Now I always get colors as I
>want to in the PopUp.  Am I currently doing things wrong then?

No, you are just doing them differnt.  Alex is using (and Leonard replied
about) the Popup Menu CDEF that was introduced with the CTB and made it into
system software as of 7.0.  You are doing it "by hand" so to speak. There are
valid reasons for doing it that way, but most CTB apps use the CDEF since
they get it for "free".

--
__________________________________________________________________________
Brian Hall                                     Internet: [e-mail]
Mark/Space Softworks                             AppleLink, AOL: MARKSPACE
Macintosh connectivity software.   info via anon ftp netcom.com:pub/mspace

+++++++++++++++++++++++++++

>From Alexander M. Rosenberg <[e-mail]>
Date: Wed, 2 Mar 1994 08:58:25 GMT
Organization: Hackers Anonymous

In article <[e-mail]> Leonard Rosenthol,
[e-mail] writes:
> > I have a DITL resource, used in a CTB setup, that has a popup menu control
in
> > it. Since the popup menu would look much more cool in color, I created a
> > 'mctb' for it in ResEdit, which displays the menu correctly. But when the
> > menu is popped up in the dialog courtesy of the Dialog Manager, it's in
bogus
> > black and white. Is there some trick to getting a popup menu control to
know
> > about an 'mctb' for its 'MENU'?
> >
>      No trick - it doesn't work!   The PopUpCDEF doesn't load the 'mctb'
> resource due to visual problems reported in earlier versions of same...

Actually, the problem is that the Popup CDEF (as of System 7.1) doesn't keep
the menu in the menulist. 'mctb' resources are menu id referential and since
the popup doesn't keep and defend an id, then 'mctb's can't be used.

Note that Inside the Macintosh Communications Toolbox and Inside Macintosh VI
don't say anywhere that 'mctb' resources are supported for popups. It was a
fluke. :-)

The workaround is to manually load a menu and associate it with the popup.
MacApp uses this technique.
---------------------------------------------------------------------------
-  Alexander M. Rosenberg  - INTERNET: [e-mail]      - Yoyodyne    -
-  330 Waverley St., Apt B - UUCP:ucbvax!apple!alexr        - Propulsion  -
-  Palo Alto, CA 94301     -                                - Systems     -
-  [phone]          - Nobody is my employer so       - :-)         -
-  [phone]          - nobody cares what I say.       -             -

---------------------------

>From [e-mail] (Chris)
Subject: TextEdit caret
Date: 19 Feb 1994 15:50:08 -0800
Organization: UC Irvine Department of ICS

I am working on a program, and have run into a slight snag.  I have a textedit
field on a grey background, so the caret doesn't show up very well...

I have looked for a way to maybe change its color, or make it thicker but to
no avail.

Any ideas?

Thanx,
Chris

-------------------------------------------------------------------------------
Chris Nowak                |Why, yes, the world does revolve around me!
[e-mail]  |Unfortunately I can't control how fast it rotates.
[e-mail]  | ...actually, it's giving me a headache...
-------------------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Peter N Lewis)
Date: 21 Feb 1994 11:56:16 +0800
Organization: NCRPDA, Curtin University

[e-mail] (Chris) writes:

>I am working on a program, and have run into a slight snag.  I have a textedit
>field on a grey background, so the caret doesn't show up very well...

Well, don't put the text on a grey background then!  Seriously, you shouldn't
really do this without the user at least having control over the field,
since the text will also be less readable.  Perhaps just use a very light grey
to differentiate it from other fields or the background?

>I have looked for a way to maybe change its color, or make it thicker but to
>no avail.

There is a TEHook for drawing the cursor if I remember correctly.  It's
presumably documented in NIM-TE.  It must be documented in IM somewhere,
otherwise I wouldn't know about it...
   Peter.
--
_______________________________________________________________________
Peter N Lewis <[e-mail]>       Ph: [phone]

+++++++++++++++++++++++++++

>From Here@There (Someone)
Date: 1 Mar 1994 21:25:19 GMT
Organization: Large Fuzzy Room

In article <2k68jg$[e-mail]>, [e-mail]
(Chris) wrote:
> I am working on a program, and have run into a slight snag.  I have a textedit
> field on a grey background, so the caret doesn't show up very well...
> I have looked for a way to maybe change its color, or make it thicker but to
Write a caret hook routine.  This allows you to draw the caret yourself, in
this case you could change it to any color you like that would show up
better against gray.  Or you could change the size.  Here's a small sample
caret hook I writ a while ago, it's in assembly, sorry, but you get the
point...

/* install the hook in the textedit record */
(*WordHandle)->caretHook=myCaretDraw;
; The actual caret hook routine

myCaretDraw proc export
 move.l (sp)+,d0             ; get the rectangle pointer
 movem.l a2-a4/d3-d7,-(sp)   ; save registers
 move.l d0,d3                ; store rect someplace safe
 pea myBackColor
 _RGBBackColor
* caretOn is a global that you use to keep track of the caret state
* now check your caretOn flag.  if true, turn it off, if false, turn it on
 move.w caretOn,d0
 bne.s @itsOn
* myForeColor is a global RGB color I was using
 pea myForeColor       ; make the caret visible
 _RGBForeColor
 moveq #1,d0
 bra.s @saveanddraw
@itsOn  pea myBackColor      ; make the caret invisible
 _RGBForeColor
 moveq #0,d0
@saveanddraw move.w d0,caretOn(a5) ; update the flag
   move.l d3,-(sp)
 _PaintRect
 movem.l (sp)+,a2-a4/d3-d7     ; restore regs
 rts     ; and go away
 endp


<TR>
Somewhere, sometime

SPA FON

---------------------------

>From [e-mail] (Lawrence Sweet)
Subject: What language should I learn?
Date: Mon, 21 Feb 1994 23:00:03 GMT
Organization: NETCOM On-line Communication Services (408 241-9760 guest)

Hello...

I've been using the Mac for about two years and now am becoming interested in
what is behind the curtain, so to speak...

I have no programming experience but I would like to learn something about how
to do so, more as a hobbyist than anything else.  I have looked through a
variety of introductory programming texts for the Mac at my local bookstore,
but I'm unsure which language to pursue or what book is well written enough to
learn from.

Could you please give me some suggestions?

Thanks in advance, Larry

(email is appreciated, also)
--
Lawrence Sweet                               "Every wave is new until it breaks"San Diego, CA           [e-mail]             --Neil Young (1981)

+++++++++++++++++++++++++++

>From [e-mail] (Daniel W. Rickey)
Date: 22 Feb 1994 16:59:48 GMT
Organization: Imaging Research Labs


For someone who has never programmed before, the language to start
with is with Pascal.  A good book to start learning macinitosh
programming
is "Macinitosh Pascal Programming Primer".  I am not sure what books
are
good for learning to programme in Pascal.

Daniel W. Rickey
drickey@.irus.rri.uwo.ca

Imaging Research Laboratories
The J.P. Robarts Research Institute
100 Perth Drive
London, Ontario
CANADA  N6A 5K8

+++++++++++++++++++++++++++

>From [e-mail]
Date: 23 Feb 94 00:10:41 MST
Organization: (none)

In article <[e-mail]>, [e-mail] (Lawrence Sweet) writes:
> Hello...
>
> I've been using the Mac for about two years and now am becoming interested in
> what is behind the curtain, so to speak...
>
> I have no programming experience but I would like to learn something about how
> to do so, more as a hobbyist than anything else.  I have looked through a
> variety of introductory programming texts for the Mac at my local bookstore,
> but I'm unsure which language to pursue or what book is well written enough to
> learn from.
>
> Could you please give me some suggestions?
>
> Thanks in advance, Larry
>
> (email is appreciated, also)
> --
> Lawrence Sweet                               "Every wave is new until it breaks"San Diego, CA           [e-mail]             --Neil Young (1981)

At the risk of flames: learn SmallTalk/V.

It will give you access to the ToolBox, but at the same time, you will learn
OOP from the ground up.


Lawson

+++++++++++++++++++++++++++

>From [e-mail] (Laurent Gasser)
Date: 23 Feb 1994 13:02:49 GMT
Organization: Ecole Polytechnique Federale de Lausanne

DO NOT learn pascal from the reference given below.

The author have never used the WITH statement. In QuickDraw
environement, it is incredible. Moreover, many examples are exactly
illustrating bad pascal design. Il looks like they just translated C
code into pascal.

If you want to learn pascal, get a book about pascal. Later on, when
you consider yourself more at ease with the language, you can look
around for a book about the Macintosh plateform. Don't mix both steps,
you will get lost.

In article <2kddm4$[e-mail]>, [e-mail] (Daniel W. Rickey) writes:
|>
|> For someone who has never programmed before, the language to start
|> with is with Pascal.  A good book to start learning macinitosh
|> programming
|> is "Macinitosh Pascal Programming Primer".  I am not sure what books
|> are
|> good for learning to programme in Pascal.
|>
|> Daniel W. Rickey
|> drickey@.irus.rri.uwo.ca
|>
|> Imaging Research Laboratories
|> The J.P. Robarts Research Institute
|> 100 Perth Drive
|> London, Ontario
|> CANADA  N6A 5K8

--
Laurent Gasser ([e-mail])

I know very few ideas worth dying for, none is worth killing.

+++++++++++++++++++++++++++

>From [e-mail] (Daniel W. Rickey)
Date: 23 Feb 1994 15:36:24 GMT
Organization: Imaging Research Labs


>DO NOT learn pascal from the reference given below.

>The author have never used the WITH statement. In QuickDraw
>environement, it is incredible. Moreover, many examples are exactly
>illustrating bad pascal design. Il looks like they just translated C
>code into pascal.

>If you want to learn pascal, get a book about pascal. Later on, when
>you consider yourself more at ease with the language, you can look
>around for a book about the Macintosh plateform. Don't mix both steps,
>you will get lost.

>In article <2kddm4$[e-mail]>, [e-mail] (Daniel W. >Rickey) writes:
|>
|> For someone who has never programmed before, the language to start
|> with is with Pascal.  A good book to start learning macinitosh
|> programming
|> is "Macinitosh Pascal Programming Primer".  I am not sure what books
|> are
|> good for learning to programme in Pascal.
|>
|> Daniel W. Rickey
|> drickey@.irus.rri.uwo.ca
|>


I recommended the book as as a reasonable one for learning how to
programme the macintosh.  I agree that it is not a good one for
learning
Pascal.
--
>Laurent Gasser ([e-mail])

>I know very few ideas worth dying for, none is worth killing.


Daniel W. Rickey
drickey@.irus.rri.uwo.ca

Imaging Research Laboratories
The J.P. Robarts Research Institute
100 Perth Drive
London, Ontario
CANADA  N6A 5K8

+++++++++++++++++++++++++++

>From [e-mail] (Peter N Lewis)
Date: 24 Feb 1994 10:56:50 +0800
Organization: NCRPDA, Curtin University

[e-mail] (Laurent Gasser) writes:

>DO NOT learn pascal from the reference given below.

>The author have never used the WITH statement. In QuickDraw
>environement, it is incredible. Moreover, many examples are exactly

Well, I know nothing about the book, so I can't comment on that.  But
I will say that not using the WITH statement is a good idea.  The WITH
statement leads to lots of very subtle errors, and generally should
be avoided.
   Peter.
--
_______________________________________________________________________
Peter N Lewis <[e-mail]>       Ph: [phone]

+++++++++++++++++++++++++++

>From [e-mail] (Daniel W. Rickey)
Date: 24 Feb 1994 15:00:54 GMT
Organization: Imaging Research Labs

>In article <2kh51i$[e-mail]>
>[e-mail] (Peter N Lewis) writes:

> [e-mail] (Laurent Gasser) writes:
>
> >DO NOT learn pascal from the reference given below.
>
> >The author have never used the WITH statement. In QuickDraw
> >environement, it is incredible. Moreover, many examples are exactly
>
> Well, I know nothing about the book, so I can't comment on that.  But
> I will say that not using the WITH statement is a good idea.  The WITH
> statement leads to lots of very subtle errors, and generally should
> be avoided.
>    Peter.
> --
> _______________________________________________________________________
> Peter N Lewis <[e-mail]>       Ph: [phone]


The with satement should not be avoided.  It should, however, be used
with
care.  One can get in trouble using it by not knowing what record a
field
belongs to.  I usually use it only when a line of code becomes too
long.

Daniel W. Rickey
drickey@.irus.rri.uwo.ca

Imaging Research Laboratories
The J.P. Robarts Research Institute
100 Perth Drive
London, Ontario
CANADA  N6A 5K8

+++++++++++++++++++++++++++

>From [e-mail] (Casgrain Philippe)
Date: Thu, 24 Feb 1994 16:25:05 GMT
Organization: Universite de Montreal

[e-mail] (Daniel W. Rickey) writes:

>>In article <2kh51i$[e-mail]>
>>[e-mail] (Peter N Lewis) writes:
>> I will say that not using the WITH statement is a good idea.  The WITH
>> statement leads to lots of very subtle errors, and generally should
>> be avoided.
>The with satement should not be avoided.  It should, however, be used with
>care.  One can get in trouble using it by not knowing what record a field
>belongs to.  I usually use it only when a line of code becomes too long.

I agree with Peter: what if you use 'with' to de-reference a handle (a
common use), and the code between the 'with' and its 'end' moves
memory? Now that could lead to nasty errors, would'nt it!

If you want to use the "with" statement, IMHO you better be sure that
your code does not move memory inside the statement. If you are not sure,
do not use "with".

Philippe
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Philippe Casgrain              Etudiant-Chercheur      [e-mail]
Departement des Sciences Biologiques                      Universite de Montreal
                  "Imitation is the sincerest form of flattery"

+++++++++++++++++++++++++++

>From [e-mail] (Chuck Shotton)
Date: Thu, 24 Feb 1994 11:37:20 -0600
Organization: Academic Computing, UT-Houston

In article <[e-mail]>,
[e-mail] (Casgrain Philippe) wrote:

> [e-mail] (Daniel W. Rickey) writes:
>
> >>In article <2kh51i$[e-mail]>
> >>[e-mail] (Peter N Lewis) writes:
> >> I will say that not using the WITH statement is a good idea.  The WITH
> >> statement leads to lots of very subtle errors, and generally should
> >> be avoided.
> >The with satement should not be avoided.  It should, however, be used with
> >care.  One can get in trouble using it by not knowing what record a field
> >belongs to.  I usually use it only when a line of code becomes too long.
>
> I agree with Peter: what if you use 'with' to de-reference a handle (a
> common use), and the code between the 'with' and its 'end' moves
> memory? Now that could lead to nasty errors, would'nt it!
>
> If you want to use the "with" statement, IMHO you better be sure that
> your code does not move memory inside the statement. If you are not sure,
> do not use "with".

Code moving memory has nothing to do with the "safety" of a with statement.
"With" is a compile-time construct that allows a shorthand notation to be
used for complex record references. The COMPILER uses the identifier
specified in the with statement, coupled with the offsets of fields within
the record to generate  references for the record fields you refer to in
the body of the with statement.

It has ABSOLUTELY nothing to do with what happens at runtime. It is merely
a shorthand convenience for the author of Pascal code to use. The same code
is generated whether a with statement or fully qualified record reference
is used.

The single biggest problem I have with the with statement is that it makes
porting Pascal code to some other language a real pain if you are trying to
automate the conversion. Not to mention the obvious readability
problems....

--_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_\_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Chuck Shotton                             \
Assistant Director, Academic Computing     \   "Are we there yet?"
U. of Texas Health Science Center Houston   \
[e-mail]  [phone] \
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-\-_-_-_-_-_-_-_-_-_-_-_-_-

+++++++++++++++++++++++++++

>From [e-mail] (Casgrain Philippe)
Date: Thu, 24 Feb 1994 19:38:38 GMT
Organization: Universite de Montreal

[e-mail] (Chuck Shotton) writes:
>Code moving memory has nothing to do with the "safety" of a with statement.
That's not what Scott Knaster says (in "How to write Macintosh Software, 3rd
edition). This book is the origin of my remarks.

Knaster used MPW Pascal, and I re-did his examples with MPW and THINK, and
you will be surprised to know that a "with" statement actually de-references
the handle/pointer/whatever in the compiled code. Hence the "may move
memory" warning.

If you want, I will be happy to fish out the exact quotation for you.

Philippe

B
>"With" is a compile-time construct that allows a shorthand notation to be
B
>used for complex record references. The COMPILER uses the identifier
>specified in the with statement, coupled with the offsets of fields within
>the record to generate  references for the record fields you refer to in
>the body of the with statement.

>It has ABSOLUTELY nothing to do with what happens at runtime. It is merely
>a shorthand convenience for the author of Pascal code to use. The same code
>is generated whether a with statement or fully qualified record reference
>is used.

>The single biggest problem I have with the with statement is that it makes
>porting Pascal code to some other language a real pain if you are trying to
>automate the conversion. Not to mention the obvious readability
>problems....

>--_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_\_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
>Chuck Shotton                             \
>Assistant Director, Academic Computing     \   "Are we there yet?"
>U. of Texas Health Science Center Houston   \
>[e-mail]  [phone] \
>_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-\-_-_-_-_-_-_-_-_-_-_-_-_-
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Philippe Casgrain              Etudiant-Chercheur      [e-mail]
Departement des Sciences Biologiques                      Universite de Montreal
                  "Imitation is the sincerest form of flattery"

+++++++++++++++++++++++++++

>From [e-mail] (Michael R. Lyle)
Date: Thu, 24 Feb 1994 13:00:33 -0800
Organization: Sonoma State University

> B
> >"With" is a compile-time construct that allows a shorthand notation to be
> B
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Philippe Casgrain              Etudiant-Chercheur      [e-mail]
> Departement des Sciences Biologiques                      Universite de Montreal
>                   "Imitation is the sincerest form of flattery"

Please note that the Pascal _STANDARD_ says that _with_ is executable.  The
orignal (Wirth) documents implied that it was only syntactic sugar, but all
implementations made it executable, so the standard was changed in about
1981.

Note:  This means that once you have done _with_ on any data item, its
address is probably in a register and that address will be used to
reference it from then until the end of the scope of the _with_ statement.
If the actual data item moves, your reference may well be invalid.

>From an old Pascal teacher who still prefers it to C and C++....
--
Michael R. Lyle
Sonoma State University
Rohnert Park, CA 94928
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Rich Siegel)
Date: Fri, 25 Feb 1994 01:44:43 GMT
Organization: Bare Bones Software

In article <[e-mail]> [e-mail] (Chuck Shotton) writes:
>
>Code moving memory has nothing to do with the "safety" of a with statement.
>"With" is a compile-time construct that allows a shorthand notation to be
>used for complex record references. The COMPILER uses the identifier
>specified in the with statement, coupled with the offsets of fields within
>the record to generate  references for the record fields you refer to in
>the body of the with statement.
>
>It has ABSOLUTELY nothing to do with what happens at runtime. It is merely
>a shorthand convenience for the author of Pascal code to use. The same code
>is generated whether a with statement or fully qualified record reference
>is used.

Oh, you think so, do you? :-)

Here is a simple counter-example.

Given this Pascal code:

program Main;

 type
  RecordType = record
    fieldA: Integer;
    fieldB: Integer;
   end;
  RecordPtr = ^RecordType;
  RecordHandle = ^RecordPtr;

 procedure P (r: RecordHandle);
 begin
  with r^^ do
   begin
    fieldA := 10;
    fieldB := 20;
   end;
 end;

 procedure Q (r: RecordHandle);
 begin
  r^^.fieldA := 20;
  r^^.fieldB := 40;
 end;

 var
  r: RecordHandle;

begin
 r := RecordHandle(NewHandle(SizeOf(RecordType)));
 p(r);
 q(r);
end.

THINK Pascal 2.0 and later will generate the following code for P and
Q, respectively:

  P
     +0000    *LINK       A6,#$0000
     +0004     MOVE.L     A4,-(A7)
     +0006     MOVEA.L    $0008(A6),A0
     +000A     MOVEA.L    (A0),A4
     +000C     MOVE.W     #$000A,(A4)
     +0010     MOVE.W     #$0014,$0002(A4)
     +0016     MOVEA.L    (A7)+,A4
     +0018     UNLK       A6
     +001A     MOVE.L     (A7)+,(A7)
     +001C     RTS

  Q
     +0000     LINK       A6,#$0000
     +0004     MOVEA.L    $0008(A6),A0
     +0008     MOVEA.L    (A0),A0
     +000A     MOVE.W     #$0014,(A0)
     +000E     MOVEA.L    $0008(A6),A0
     +0012     MOVEA.L    (A0),A0
     +0014     MOVE.W     #$0028,$0002(A0)
     +001A     UNLK       A6
     +001C     MOVE.L     (A7)+,(A7)
     +001E     RTS

Note that in P, the generated code places p^ into a register (a4 in this
case), and then stores relative to the register.

In Q, p^ is repeatedly generated into a temp (a0, in this case) which
is then used to store.

The WITH-clause is not a simple syntactic shorthand. The compiler is
free to use the presence of a WITH-clause as a hint to the code
generator to generate more efficient code, and most 68K Pascal
compilers I've seen avail themselves of this hint.

R.

--
Rich Siegel % [e-mail]    % Principal, Bare Bones Software
--> For information about BBEdit, finger [e-mail] <--

"He then proceeded to give a history of the universe, in real time."

+++++++++++++++++++++++++++

>From [e-mail] (Daniel W. Rickey)
Date: 25 Feb 1994 15:21:20 GMT
Organization: Imaging Research Labs

In article <[e-mail]>
[e-mail] (Rich Siegel) writes:

> The WITH-clause is not a simple syntactic shorthand. The compiler is
> free to use the presence of a WITH-clause as a hint to the code
> generator to generate more efficient code, and most 68K Pascal
> compilers I've seen avail themselves of this hint.
>
> R.
>
> --
> Rich Siegel % [e-mail]        % Principal, Bare Bones Software


Well, one learns something new everyday.  I too thought the with
statement did not affect the code generation.  Does this mean that we
should never use a With statement to dereference a handle?  I tend to
use the With statement only to dereference pointers.

Daniel W. Rickey
drickey@.irus.rri.uwo.ca

Imaging Research Laboratories
The J.P. Robarts Research Institute
100 Perth Drive
London, Ontario
CANADA  N6A 5K8

+++++++++++++++++++++++++++

>From [e-mail] (Francois Pottier)
Date: 25 Feb 1994 16:27:09 GMT
Organization: Ecole Normale Superieure, PARIS, France

In article <2kh51i$[e-mail]>,
Peter N Lewis <[e-mail]> wrote:

>I will say that not using the WITH statement is a good idea.  The WITH
>statement leads to lots of very subtle errors, and generally should
>be avoided.

Well, I beg to differ. I'd rather say: the Mac Memory Manager leads to lots
of very subtle errors, and you should generally avoid using
  with theHandle do
or
  with theObject do
constructs, unless you are certain not to move memory.

Also, OOP can be dangerous. Since every method contains a implicit
"with Self do" construct, moving memory could move your object from under you.

If you know about those pitfalls and carefully avoid them, there is nothing
wrong with the with construct... For instance, when filling a parameter
block, using a with construct is much more elegant than the C way:

paramBlock.ioVRefNum = ...
paramBlock.ioDirID = ...

which is very redundant.

Cheers,

--
Francois Pottier            ___ ___  _    _  / ___  ___    ___
[e-mail]       /_  /__/ /_|  /| / /  / /  / / /__
              /   / \  /  | / |/ /___ /__/ / ___/ _
                          /

+++++++++++++++++++++++++++

>From [e-mail] (Matt Mora)
Date: 25 Feb 1994 08:27:47 -0800
Organization: SRI International, Menlo Park, CA

In article <2kl51g$[e-mail]> [e-mail] (Daniel W. Rickey) writes:
>In article <[e-mail]>
>[e-mail] (Rich Siegel) writes:

>> The WITH-clause is not a simple syntactic shorthand. The compiler is
>> free to use the presence of a WITH-clause as a hint to the code
>> generator to generate more efficient code, and most 68K Pascal
>> compilers I've seen avail themselves of this hint.

>Well, one learns something new everyday.  I too thought the with
>statement did not affect the code generation.  Does this mean that we
>should never use a With statement to dereference a handle?  I tend to
>use the With statement only to dereference pointers.


Works with handles just fine. Just lock them first. I was supprised to see
Peter bash this cool feature of Pascal. I was told that features like
this help Pascal compilers optimize code better than c ever could.

Xavier







--
___________________________________________________________
Matthew Xavier Mora                    [e-mail]
SRI International                       [e-mail]
333 Ravenswood Ave                    Menlo Park, CA. 94025

+++++++++++++++++++++++++++

>From [e-mail] (Casgrain Philippe)
Date: Fri, 25 Feb 1994 19:24:45 GMT
Organization: Universite de Montreal

[e-mail] (Francois Pottier) writes:

>Well, I beg to differ. I'd rather say: the Mac Memory Manager leads to lots
>of very subtle errors, and you should generally avoid using
>  with theHandle do
>or
>  with theObject do
>constructs, unless you are certain not to move memory.

Well ;-> if you are not certain about the moving memory stuff (some
toolbox calls move memory indirectly, by calling other toolbox calls that
themselves move memory), you can always lock your handles before the
"with" (HLock) and unlock them after (HUnlock). Be careful not to leave
your handles locked for too long, as your heap will become fragmented.

On a related note, the TB calls that move memory usually are documented
as such (for example, there's the little "memory chip" icon in THINK
Reference), but there are probably some errors and omissions, although I
can't think of any offhand. Anyone? Anyone?

Philippe
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Philippe Casgrain              Etudiant-Chercheur      [e-mail]
Departement des Sciences Biologiques                      Universite de Montreal
                  "Imitation is the sincerest form of flattery"

+++++++++++++++++++++++++++

>From [e-mail] (Rich Siegel)
Date: Fri, 25 Feb 1994 20:20:44 GMT
Organization: Bare Bones Software

In article <2kl51g$[e-mail]> [e-mail] (Daniel W. Rickey) writes:
>
>Well, one learns something new everyday.  I too thought the with
>statement did not affect the code generation.  Does this mean that we
>should never use a With statement to dereference a handle?  I tend to
>use the With statement only to dereference pointers.

"never" is a little strong. Use it any way you like, but just be aware
of the implications when you do.

R.

--
Rich Siegel % [e-mail]    % Principal, Bare Bones Software
--> For information about BBEdit, finger [e-mail] <--

"He then proceeded to give a history of the universe, in real time."

+++++++++++++++++++++++++++

>From [e-mail] (Chuck Shotton)
Date: Fri, 25 Feb 1994 19:43:38 -0600
Organization: UT Houston Academic Computing

In article <[e-mail]>, [e-mail] (Rich Siegel)
wrote:

> In article <[e-mail]> [e-mail] (Chuck Shotton) writes:
>
> Oh, you think so, do you? :-)
>
> Here is a simple counter-example.
> [code snipped]
> The WITH-clause is not a simple syntactic shorthand. The compiler is
> free to use the presence of a WITH-clause as a hint to the code
> generator to generate more efficient code, and most 68K Pascal
> compilers I've seen avail themselves of this hint.

You are correct. Mac compiler writers have implemented the "with" in a
non-safe fashion. The Jensen & Wirth book never indicates how code is to be
generated for this statement, but very clearly identifies it as a syntactic
short cut rather than a cue to the code generator. To me, that should
indicate that the non-safe code generated by Mac compilers when
dereferenced pointers and handles are "withed" is not exactly compliant
with the standard.

-----------------------------------------------------------------------
Chuck Shotton
[e-mail]                           "I am NOT here."

+++++++++++++++++++++++++++

>From [e-mail] (Peter N Lewis)
Date: 27 Feb 1994 12:46:09 +0800
Organization: NCRPDA, Curtin University

[e-mail] (Matt Mora) writes:

>Works with handles just fine. Just lock them first. I was supprised to see
>Peter bash this cool feature of Pascal. I was told that features like
>this help Pascal compilers optimize code better than c ever could.

True, that and for loops and generally many fewer pointers (pointers confuse
the heck out of optimizers in general).

The with statement has its place, but it must be used very causiously.  It
can cause problems if you do "with h^" and the handle moves inside the with
statement.  It can cause problems if you "with rec", and rec contains fields
that clash with global or local variables (this is especially painful when
global or local variables clash with object variables, since THINK Pascal
puts in a "with self" implicitly).  It's also interesting to note that most
compilers won't generate less efficient code for these two:

pb.a := 1;
pb.b := 2;
..

as compared with

with pb do begin
  a := 1;
  b := 2;
  ...
end;

In any event, my advice, especially to beginning programmers is to
avoid the with statement as a general rule until you really understand
what it does and what its dangers are.  Of course, you can't avoid the
implicit "with self", so you better learn about those dangers pretty quick!
   Peter.
--
Peter N Lewis <[e-mail]>       Ph: [phone]

+++++++++++++++++++++++++++

>From [e-mail] (Peter N Lewis)
Date: 27 Feb 1994 12:49:57 +0800
Organization: NCRPDA, Curtin University

[e-mail] (Casgrain Philippe) writes:

>On a related note, the TB calls that move memory usually are documented
>as such (for example, there's the little "memory chip" icon in THINK
>Reference), but there are probably some errors and omissions, although I
>can't think of any offhand. Anyone? Anyone?

My policy is to assume everything can move memory except BlockMove,
PBRead and PBWrite (and FSRead and FSWrite).  As a general rule, they
are the only common routines that you use with handle data that are
handle-safe.  Remember that you aren't only dealing with what the OS does
now, but also what it might do in the future (witness SysBeep), and
also what broken inits (like some from Apple! ;-) that change the
memory-safeness of routines.
   Peter.
--
Peter N Lewis <[e-mail]>       Ph: [phone]

+++++++++++++++++++++++++++

>From [e-mail] (Quinn "The Eskimo!")
Date: 27 Feb 1994 13:29:06 +0800
Organization: The University of Western Australia

[e-mail] (Matt Mora) writes:

>[...] I was supprised to see
>Peter bash this cool feature of Pascal. I was told that features like
>this help Pascal compilers optimize code better than c ever could.

But Pete uses Pascal because it's safer, not because it produces better
code.  The with statement is wildly unsafe because it brings identifiers
into scope with very little warning.  [In that respect it's very like
Pascal's uses clause which is also braindead, especially wehn compared
to Modula 2's import/export mechanism.]

What I'd like to see is the with statement redone so that it doesn't
introduce new identifiers invisibly.  For example instead of doing
this...

  with graf_ptr^.pnLoc do begin
    frog := h;
  end; (* with *)

you get something more like this...

  with my_pn_loc ::= graf_ptr^.pnLoc do
    frog := my_pn_loc.h;
  end-with;

The second version introduces a name for the temporary result, which
you then use in a qualified fashion.  Much safer IMHO.

--
Quinn "The Eskimo!"      <[e-mail]>     "Support HAVOC!"
Department of Computer Science, The University of Western Australia
  I hate unix!!!  I hate nn!!!  I wan't my static IP number back ):
--

Quinn "The Eskimo!"      <[e-mail]>     "Support HAVOC!"
Department of Computer Science, The University of Western Australia
  I hate unix!!!

+++++++++++++++++++++++++++

>From [e-mail] (Peter N Lewis)
Date: 28 Feb 1994 11:25:24 +0800
Organization: NCRPDA, Curtin University

[e-mail] (Chuck Shotton) writes:

>You are correct. Mac compiler writers have implemented the "with" in a

It's not just Mac compilers, it's how every compiler I've ever seen (and
indeed every compiler I've ever written!) has implemented the with statement.
If thats not part of the standard, then it's the standard that is wrong.
But the fact is that it doesn't matter which way it's implemented, this
would still be dangerous:

with p^ do begin
  Dispose(p);
  x := 5;
end;

Where x is a local variable and a field of p^.  The only reason it is
unsafe with handles is because of the Mac's treatment of handles as
movable.  But it would still be unsafe under other OSes if other conditions
like the above happened.
   Peter.
--
Peter N Lewis <[e-mail]>       Ph: [phone]

+++++++++++++++++++++++++++

>From [e-mail] (DAG GILLIES)
Date: Mon, 28 Feb 1994 13:28:18 GMT
Organization: University of Bradford, UK

In article <2kl8u3$[e-mail]> [e-mail] (Matt Mora) writes:
>In article <2kl51g$[e-mail]> [e-mail] (Daniel W. Rickey) writes:
>>In article <[e-mail]>
>>[e-mail] (Rich Siegel) writes:
>
>>> The WITH-clause is not a simple syntactic shorthand. The compiler is
>>> free to use the presence of a WITH-clause as a hint to the code
>>> generator to generate more efficient code, and most 68K Pascal
>>> compilers I've seen avail themselves of this hint.
>
>>Well, one learns something new everyday.  I too thought the with
>>statement did not affect the code generation.  Does this mean that we
>>should never use a With statement to dereference a handle?  I tend to
>>use the With statement only to dereference pointers.
>
>
>Works with handles just fine. Just lock them first. I was supprised to see
>Peter bash this cool feature of Pascal. I was told that features like
>this help Pascal compilers optimize code better than c ever could.
>

Am I missing something here, or am I mistaken when I recall that in the first
few pages of Volume I of (old) Inside Mac, there is a specific warning
about locking handles before dereferencing them, and that the Pascal WITH
statement can cause an implicit dereference. There was a code fragment
along the lines of

HLock(aHandle)

WITH aHandle DO
    ...
    ...
    ...

HUnlock(aHandle)


I mean, if it's in IM, why all the controversy?


______________________________________________________
David A. G. Gillies     ([e-mail])
(c) 1994 Wittgenstein's Amazing Underwater Supermarket

---------------REPLIES VIA EMAIL PLEASE---------------
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

+++++++++++++++++++++++++++

>From [e-mail] (Matthias Neeracher)
Date: 28 Feb 94 17:38:00
Organization: Integrated Systems Laboratory, ETH, Zurich

In article <[e-mail]>, [e-mail] (Chuck Shotton) writes:

> In article <[e-mail]>, [e-mail] (Rich Siegel)
> wrote:
>> The WITH-clause is not a simple syntactic shorthand. The compiler is
>> free to use the presence of a WITH-clause as a hint to the code
>> generator to generate more efficient code, and most 68K Pascal
>> compilers I've seen avail themselves of this hint.

> You are correct. Mac compiler writers have implemented the "with" in a
> non-safe fashion. The Jensen & Wirth book never indicates how code is to be
> generated for this statement, but very clearly identifies it as a syntactic
> short cut rather than a cue to the code generator. To me, that should
> indicate that the non-safe code generated by Mac compilers when
> dereferenced pointers and handles are "withed" is not exactly compliant
> with the standard.

A few comments:

 - Jensen & Wirth is not the Pascal Standard.
 - At least one ETH Modula-2 compiler, which certainly was authorized by Wirth,
   does no register allocation except to use two of the address registers
   for the two innermost WITH statements.
 - I would suspect that something similar was done for many Pascal compilers.
 - The reason why this is not mentioned is probably that J&W were not concerned
   with such problems, and indeed, this problem is not very important outside
   of a handle based environment.

Matthias

-----
Matthias Neeracher                                [e-mail]
   "One fine day in my odd past..." -- Pixies, _Planet of Sound_

+++++++++++++++++++++++++++

>From [e-mail] (Michael Peirce)
Date: Mon, 28 Feb 94 10:42:19 PST
Organization: Peirce Software, Inc.


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Chuck Shotton) writes:
> In article <[e-mail]>, [e-mail] (Rich Siegel)
> wrote:
>
> > In article <[e-mail]> [e-mail] (Chuck Shotton) writes:
> >
> > Oh, you think so, do you? :-)
> >
> > Here is a simple counter-example.
> > [code snipped]
> > The WITH-clause is not a simple syntactic shorthand. The compiler is
> > free to use the presence of a WITH-clause as a hint to the code
> > generator to generate more efficient code, and most 68K Pascal
> > compilers I've seen avail themselves of this hint.
>
> You are correct. Mac compiler writers have implemented the "with" in a
> non-safe fashion. The Jensen & Wirth book never indicates how code is to be
> generated for this statement, but very clearly identifies it as a syntactic
> short cut rather than a cue to the code generator. To me, that should
> indicate that the non-safe code generated by Mac compilers when
> dereferenced pointers and handles are "withed" is not exactly compliant
> with the standard.

Don't blame just Mac Pascal compilers.  I know of at least one PDP-11
Pascal compiler that does this same thing.  I expect there are others.
(I think the VAX Pascal compiler did this too)

Frankly, I wish there was a similar construct in c - or at least C
compilers that were smart enough to dereference a struct into a register
instead of constantly redereferencing.  The Pascal code is much more
efficient in this case.  (A good example of this is filling in a BIG
parameter block).


-- Michael Peirce        -- [e-mail]
-- Peirce Software, Inc. -- 719 Hibiscus Place, Suite 301
--                       -- San Jose, California USA 95117
-- Makers of: Smoothie & -- voice: +1.408.244.6554 fax: [phone]
--    Peirce Print Tools -- AppleLink: peirce & America Online: AFC Peirce

+++++++++++++++++++++++++++

>From [e-mail] (Gary Kacmarcik)
Date: 02 Mar 1994 01:01:15 GMT
Organization: Case Western Reserve University, Cleveland, Ohio (USA)

In article <[e-mail]> [e-mail] (Michael Peirce) writes:
> In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Chuck Shotton) writes:
> > In article <[e-mail]>, [e-mail] (Rich Siegel)
> > wrote:
> > >
> > > The WITH-clause is not a simple syntactic shorthand. The compiler is
> > > free to use the presence of a WITH-clause as a hint to the code
> > > generator to generate more efficient code, and most 68K Pascal
> > > compilers I've seen avail themselves of this hint.
> >
> > You are correct. Mac compiler writers have implemented the "with" in a
> > non-safe fashion. The Jensen & Wirth book never indicates how code is to be
> > generated for this statement, but very clearly identifies it as a syntactic
> > short cut rather than a cue to the code generator. To me, that should
> > indicate that the non-safe code generated by Mac compilers when
> > dereferenced pointers and handles are "withed" is not exactly compliant
> > with the standard.
>
> Don't blame just Mac Pascal compilers.  I know of at least one PDP-11
> Pascal compiler that does this same thing.  I expect there are others.
> (I think the VAX Pascal compiler did this too)
>
> Frankly, I wish there was a similar construct in c - or at least C
> compilers that were smart enough to dereference a struct into a register
> instead of constantly redereferencing.  The Pascal code is much more
> efficient in this case.  (A good example of this is filling in a BIG
> parameter block).

ummm...

i don't understand your comment that Pascal is "much more efficient"
in this case.  without the "with" statement, comparable compilers
should generate code which is equally "bad".

if you have the "with" statement in Pascal, then you need to add
the equivalent in C: which is an assignment statement which saves
the dereferenced handle/ptr.  again, the code should be comparable.
(if not, you should get a better compiler ;-)

C expects you to explicitly store the value in a temp variable, which
is exactly what the "with" statement (as described above) does.  i
don't see any real need for a "with" statement - it makes the
code slightly less explicit and potentially confusing (eg: with
multiple "with"s into structures that have fields/records with the
same name).

being explicit (either in C or Pascal) makes the code more readable:
i detest reading Pascal code where the programmer uses multiple
nested "with" statements because it makes it much more difficult to
identify which struct the field belongs to.


-gary j kacmarcik
[e-mail]



---------------------------

End of C.S.M.P. Digest
**********************